-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More exhaustive feature test macro checks #2545
More exhaustive feature test macro checks #2545
Conversation
Do you still have access to this compiler? I'm asking because, as far as I can see, it won't pass the Line 79 in dcd282b
and it's unmodified in this PR. Also, there are other usages of this feature macro in compile.h :Line 159 in dcd282b
Line 538 in dcd282b
that probably should also be changed since they depend on each other. |
Thanks for pointing this out! I was able to extend the conditional blocks mentioned above and ran into another bug in Intel (minimal example here) that I went ahead and added a patch for. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. Looks good but please address minor inline comments.
I can also suggest regrouping changes to 2 commits differently than it's done now - the first one for all |
… are available fix: remaining ifdefs
9e3efc8
to
6a7d900
Compare
Good suggestion, the two changes have been moved into their own commits. |
This was discovered when using a compiler that supports
if constepxr
but not automatic return type deduction, which is used by theget
function defined within this block. I was able to mitigate this by adding a check to make sure automatic return type deduction was also supported.